Windows では、UI 要素、ファイル名などの Unicode 文字列がネイティブにサポートされています。 Unicode は、すべての文字セットと言語をサポートしているため、推奨される文字エンコードです。 Windows は、UTF-16 エンコードを使用して Unicode 文字を表します。各文字は 1 つまたは 2 つの 16 ビット値としてエンコードされます。 UTF-16 文字は ワイド 文字と呼ばれ、8 ビット ANSI 文字と区別されます。 Visual C++ コンパイラでは、ワイド文字の組み込みデータ型 wchar_t がサポートされています。 ヘッダー ファイル WinNT.h では、次の typedef も定義されます。

MSDN サンプル コードに両方のバージョンが表示されます。 ワイド文字リテラルまたはワイド文字文字列リテラルを宣言するには、リテラルの前に L を配置します。

表示されるその他の文字列関連の typedef を次に示します。

Microsoft が Windows に Unicode サポートを導入したとき、ANSI 文字列用と Unicode 文字列用の 2 つの並列 API セットを提供することで、移行を容易にしました。 たとえば、ウィンドウのタイトル バーのテキストを設定する 2 つの関数があります。

内部的には、ANSI バージョンでは文字列が Unicode に変換されます。 また、Windows ヘッダーでは、プリプロセッサ シンボル UNICODE が定義されている場合は Unicode バージョンに解決されるマクロ、それ以外の場合は ANSI バージョンが定義されます。

MSDN では、関数は SetWindowText という名前で文書化されていますが、実際にはマクロ名であり、実際の関数名ではありません。

新しいアプリケーションでは、常に Unicode バージョンを呼び出す必要があります。 多くの世界言語では Unicode が必要です。 ANSI 文字列を使用すると、アプリケーションをローカライズできなくなります。 また、オペレーティング システムでは実行時に ANSI 文字列を Unicode に変換する必要があるため、ANSI バージョンも効率が低くなります。 好みに応じて、 SetWindowTextW などの Unicode 関数を明示的に呼び出すか、マクロを使用できます。 MSDN のコード例では通常、マクロが呼び出されますが、2 つの形式はまったく同じです。 Windows のほとんどの新しい API には Unicode バージョンがあり、対応する ANSI バージョンはありません。

アプリケーションがWindows NTと Windows 95、Windows 98、および Windows Me の両方をサポートする必要がある場合、ターゲット プラットフォームに応じて ANSI 文字列または Unicode 文字列に対して同じコードをコンパイルすると便利でした。 このため、Windows SDK には、プラットフォームに応じて文字列を Unicode または ANSI にマップするマクロが用意されています。

コード例を次に示します。

は次のいずれかに解決されます。

現在、TEXT マクロと TCHAR マクロは、すべてのアプリケーションで Unicode を使用する必要があるため、あまり役に立ちません。 ただし、古いコードや MSDN コード例の一部で表示される場合があります。

Microsoft C ランタイム ライブラリのヘッダーは、同様のマクロ セットを定義します。 たとえば、_tcslen が未定義の場合_UNICODEは strlen に解決されます。それ以外の場合は、ワイド文字バージョンの strlen である wcslen に解決されます。

注意: 一部のヘッダーではプリプロセッサ シンボル UNICODEが使用され、他のヘッダーではアンダースコア プレフィックスが使用 _UNICODE されます。 常に両方のシンボルを定義します。 Visual C++ では、新しいプロジェクトを作成するときに両方が既定で設定されます。

ウィンドウとは